1. Field of the Invention
This invention relates to computing systems, and more particularly to the architecture and environment for computing and applications executing therein.
Portions of the disclosure of this patent document contain material that is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure as it appears in the Patent and Trademark Office file or records, but otherwise reserves all copyright rights whatsoever. Sun, Sun Microsystems, the Sun logo, Solaris, SPARC, Java, JavaBeans and all Java-based trademarks and logos are trademarks or registered trademarks of Sun Microsystems, Inc. in the United States and other countries.
2. Background Art
Computers are used to send and receive data using a transport mechanism or communications network. The Internet is one example of a transport mechanism and other examples include local area networks (LANs) and wide area networks (WANs). Using a network, a software application (a sender) that resides on one computer system can exchange information (e.g., corporate data or executable code) with a software application (a receiver) that resides on a remote computer system, for example. The exchange of information between computers typically occurs between a “server application” that provides information or services, and a “client application” that receives the provided information and services.
A problem with existing server applications is that they must be pre-configured to include the information that they are to provide to a client application (they cannot be configured dynamically). Additionally, files that are needed to execute an application are transferred one at a time as they are needed thereby delaying the execution time for various applications. Thus, instead of having all files that are utilized by an application transferred prior to execution (thereby expediting the actual execution), each file is transferred as it is needed. Further, when information or an application is updated, the updates have to be manually retrieved and installed. Additionally, disk space on a server must be managed by a user to relieve disk space for further use. Issues such as transmission efficiency and security are raised when information is exchanged between computers. Transmission inefficiencies are especially apparent where information is communicated over a long distance and/or lower speed or bandwidth lines. Further, where a transmission is being received by a computer system, security measures are typically used to ensure that the transmitted information (e.g., program code) does not corrupt the computer system. Unfortunately, security measures can restrict access to the computer system's resources which can hinder an application's efficiency and usability.
As will be discussed below, computing environments that use an application architecture initially developed for use with the Internet can be significantly affected by the type of medium used to form the Internet connection. The type of connection that a user has to the Internet can impact the speed at which information is transmitted.
The application architecture that is typically used in the Internet environment is referred to as a three-tier application architecture, or three-tier architecture. The three-tier architecture was originally designed to allow a client to have access to data and applications. In this architecture, a client communicates requests to a server for data, software and services, for example. The three-tier architecture includes a database tier that includes a database server, an application tier that includes an application server and application logic (i.e., software application programs, functions, etc.), and a client tier. The application server responds to application requests (e.g., a request for a software applet, etc.) received from the client. The application server forwards data requests to the database server.
The number of tiers that are required for an application may vary. For example, a calculator application might only involve the client tier. That is, if the calculator application software and data are resident on the client, there is no need to access the application or database tiers. An application that makes use of persistent storage such as a word processing application and the documents created therein may involve both the client and the application tiers. An enterprise's application (e.g., an accounting or personnel) application may involve all three tiers as data that is used by the application may be stored in a database.
FIG. 1 provides an overview of a three-tier architecture. Client tier 102 typically consists of a computer system that provides a graphic user interface (GUI) generated by browser 106. Browser 106 generates a display from a specification of GUI elements (e.g., a file containing input, form, and text elements defined using the Hypertext Markup Language (HTML) and/or by an applet (i.e., a program such as a program written using the Java programming language that runs when it is loaded by the browser).
Application server 110 is pre-configured to include those applications that are needed by its clients. In an effort to keep the size of the client minimal or “thin,” applets that are executed in client tier 102 generally do not include any significant application logic. Application server 110 is pre-configured to include the application logic that is not included in client tier 102. The majority of an application's functionality is performed by the application logic that resides on and is managed by application server 110 in application tier 116. Database tier 118 contains the data that is accessed by the application logic in application tier 116. Database server 112 manages the data, its structure and the operations that can be performed on the data and/or its structure.
Application server 110 and database server 112 reside in production data center 108. Application server 110 can be pre-configured with applications such as a corporation's accounting, personnel and payroll applications, for example. Application server 110 manages requests directed to the applications that are stored on application server 110. Database server 112 manages the database(s) that manage data for applications. Database server 112 responds to request to access the accounting, personnel and payroll applications' data, for example.
Connection 104 is used to transfer code, data, and graphical user interface layer to client tier 102 and to transmit enterprise data between client tier 102 and production data center 108. The client tier can communicate with the application tier using various protocols including HTTP (HyperText Transfer Protocol), HTTPS (Secure Hyper Text Transfer Protocol), Socket, CORBA, or an RMI (a Remote Method Invocation) application programming interface (API) available from Sun Microsystems. The RMI API provides the ability to invoke methods, or software modules, that reside on another computer system. Parameters are packaged (or marshalled) and unpackaged (or unmarshalled) for transmittal to and from the client tier. Connection 114 represents the transmission of requests for data and the responses to such requests from applications that reside in application server 110.
In a typical computing environment, production data center 108 is located at a centralized site. In this way, applications can be centrally managed such that updates can be made and a standardized application base can be provided to users. However, an application's users can be spread across a wide geographical area. Thus, client tier 102 is not necessarily located at the same site or proximately connected to application server 110 (e.g., via a local area network, or LAN). Information may be transmitted, for example, via a wide area network (WAN) or the Internet that involve remote transmissions (e.g., overseas) and lower bandwidth communication technologies (e.g., modem) which can result in unacceptable transmission times. Transmission times are of concern since both data and application code may be transmitted between client tier 102 and application server 110 in the three-tier architecture.
The three-tier architecture can be used with various types of networks (e.g., Internet and intranet). Typically, client tier 102 communicates with production data center 108 via browser 106 which issues a request of application server 110. The client can request a resource that is identified by a uniform resource locator (URL) designation. For example, the URL can identify a page definition (e.g., an HTML document) that browser 106 uses to generate a display, or the URL can identify page definition with an embedded applet (i.e., executable program code) that is run inside browser 106).
The information that is represented by a URL is downloaded to client tier 102. Thus, if a corporate application requires multiple downloads (e.g., multiple page definitions and/or applets) to run within client tier 102, the downloading process is inefficient when application server 110 is remote and/or slower transmission rates are used. Web applications (where the client is using a browser as the application container), often do not store code, nor data in the disk on client tier 102. All information is retrieved from the application server 110 every time. Further, when information may be stored within client tier 102 (for example when a client is the tuner Castanet product available from Marimba discussed below), the information downloaded to client tier 102 may occupy a significant amount of client tier 102's disk space. To free up memory and disk space on client tier 102, a user has to manually delete unused applications.
One type of application that can be used for distributing, updating, and managing business applications and accompanying information on the client is the Castanet product available from Marimba. The Castanet product consists of a tuner (client software that resides on the desktop or computing device) and transmitter (server software). A tuner can receive, install, and launch applications automatically without intervention. When a network connection is available, the tuner looks for updates to the installed applications and selectively downloads only the information that has changed. The transmitter distributes and updates applications over a network. Information and applications distributed and managed by the Castanet product through the transmitters and receivers are referred to as channels. Thus, the Castanet product may be utilized to distribute and manage channels. However, the tuner for the Castanet product is required in order to receive the transferred information.
Security measures adopted for use with the application architecture limit the applications that have been developed according to this architecture. For example, an application's efficiency and/or usability can be impacted as a result of security measures. Further, there are issues of security concerning the transmission of information. From the perspective of client tier 102, for example, it is necessary to ensure that the information that is being received is “trusted.” That is, it is important to ensure that client tier 102 is not corrupted by unauthorized software executing in client tier 102. Further, it is important to ensure that a client that attempts to access production data center 108 can be trusted with the corporation's data and applications.
Optimally, client tier 102 executes only those applets that have been received from a known and trusted source (e.g., production data center 108). A level of trust can be achieved between a client tier 102 and production data center 108 such that data and applets can be transmitted freely between client tier 102 and production data center 108. However, this paradigm is limiting and does not always occur in practice. Browser 106 may request an applet from a source other than production data center 108, for example. If an applet is allowed to execute unchecked in client tier 102, it introduces the potential for serious breaches of security and/or malicious access to the data and resources.
Security models or approaches have been adopted to limit the damage that may be caused by a breach of security and maliciousness. One such security approach, referred to as the sandbox security model, limits the access given to applets from an “untrusted” (i.e., unknown) source to only its namespace (e.g., operating system-assigned boundaries of a program such as the addressable memory). For example, normally, applets run within a browser's sandbox model, due to which the applets are not allowed to access any local resources like file systems and printers. The only way to access file systems and printers is from the application server which is normally in a remote location. Such a solution is not efficient and may not provide access to resources close to a client. Under the sandbox model, one solution to this problem is to use signed applets that make the applets trusted, thereby allowing the applets to use the local resources. Further, when applets are downloaded from an application server, the applets can only communicate with the application server. Thus, it is not possible to share services by applets downloaded from different application servers.
An “untrusted” applet or software program is allowed to access only memory or other computer resources that are in its namespace. By limiting an “untrusted” applet to its own namespace, the applet can be prohibited from modifying areas of memory assigned to other applets or applications, for example.
Further, an applet may be prohibited from establishing a connection to (and/or downloading code from) a server (e.g., file or printer servers) other than the one from which it was retrieved. Client tier 102 may be forced to access another server via application server 110. To make a request of a file server, for example, client tier 102 sends the request to application server 110 which forwards the request to the file server. This is inefficient particularly when the file server adjacent to client tier 102.
Further, in the sandbox approach, printing is accomplished by displaying material to be printed in browser 106 and relying on the user to print the material using the print functionality available in browser 106.
The sandbox approach has clear disadvantages. An applet that is confined to its namespace cannot access information that is stored in a local file system. Further, confined applets cannot pool or share resources such as memory.
Another security approach uses signatures or other forms of certification to certify that an applet is from a known source. An “untrusted” applet can become a “trusted” applet, if its digital signature can be verified by, for example, client tier 102. Verification can be accomplished with digital signatures using a public key/private key encryption technique. The recipient of the information (e.g., client tier 102) uses the digital signature and a public key (a key generated from the private key and distributed to the public) to verify the digital signature thereby verifying the information.
Signed applet support is not provided by all clients. To support digitally signed applets, it is necessary for client tier 102 to include the ability to verify the signature. Many currently available browsers do not have such a capability.
In addition to the efficiency, memory, and security issues, in the three-tier model each application must log in to application server 110 separately. There is no ability to store user information (e.g., profile information) in client tier 102 or elsewhere so that it can be used for subsequent applications.